Talk:Unreachable code

Merging in Dead code

I'm merging in the contents from Dead code. I'll post an update here when I'm done. Jamie 21:54, 13 November 2005 (UTC)

Merge done. Jamie 22:48, 13 November 2005 (UTC)

The article should be merget to dead code as an example, and a link should go from here to there. Sae1962 (talk) 18:07, 26 December 2011 (UTC)

-- Perfect unreachability rules are impossible -- The article claims that "it is infeasible to choose rules that are equivalent to true unreachability". In fact, it's worse than that — it is impossible in principle. One cannot have a ruleset which, in finite time, correcly finds all unreachable code. This is equivalent to the halting problem. I'm going to change the article to reflect this, once I can figure out how to do so without disrupting the narrative.

Unreachable vs dead code

I'm a decompilation researcher, and I see unreachable and dead code as completely different. To me, dead code is code generating a definition for which there are no further uses. This happens all the time in decompilation, through the effects of expression propagation (the original expression assignment becomes dead code), and the fact that many machine instructions have semantics that are unused (e.g. it is rare to use both the remainder and the quotient after a divide instruction; it is common to ignore the assignments to the flags after an arithmetic or logical instruction, and so on). By contrast, unreachable code is less common, and this requires control flow analysis.

Surely compilers see dead code (according to my definition), just perhaps less frequently. Let's suppose that your machine code target is a RISC machine, which has three address instructions and no explicit move instructions. Suppose the source code is

 x = a+b;
 printf("I'm about to use %d\n", x);
 useit(x);

Here before optimisation the compiler needs to move x to the register where the second argument is passed, then to the first one. But each move instruction is probably an add or or instruction anyway; if a and b are already available in registers, you would probably optimise this, in the IR (intermediate representation), to effectively

 x = a+b;          /* Now dead code */
 printf("I'm about to use %d\n", a+b);
 useit(a+b); 

This is expression propagation, not used much in compilers, as the idea is usually to make the expressions simpler, not more complex, so that individial machine instructions can match to the simple semantics. But in this case, an add is just as easy as a move, so expression propagation is useful. Now the code for x=a+b is dead. Note it is dead, not unreachable; it effectively does get executed (twice, in fact), but the IR for the original definition of x can be removed, since the result in x is no longer used.

My other concern is that you state right near the start of the article that dead code (through its equivalence to unreachable code) is source code. Surely dead code can arise in the intermediate code of a compiler or decompiler, which has little relationship to the original source code. In the example above, it is really the intermediate code defining x that is dead, and only after an optimisation; by most definitions, the definition of x is not dead at the source code level. Note that when rearranging basic blocks to take care of delay slot instructions and the like you can end up with unreachable code in the IR that is not in the original code (source or binary code). So I would prefer "is source code or intermediate representation", or the like, for both dead and unreachable code. I think it's OK to keep dead and unreachable code in the same article, since they are very similar, and you do the same thing with both (delete them).

Now, I don't want to make a change that only makes sense to a minority of readers; compilation is obviously much more commonly researched than decompilation. So I'd value some comments from the compiler community before making changes to the article. --Mike Van Emmerik 23:22, 12 February 2006 (UTC)

Is it dead?

Is code considered dead if it is reachable, but in normal operation is never called? For example, suppose you write a routine that parses BMP files, including support for 8-bit-per-pixel images, but only use it to parse BMP files embedded into your program and don't end up adding any that are 8 bits per pixel. The 8bpp routine is reachable, but will never be called since there aren't any 8bpp files. Is this considered dead code? 142.59.172.187 11:47, 10 June 2007 (UTC)

dead code movie

anyone feel like adding something about it? or possibly why true english is starting to be referred to as dead code? proof of word battles would be an excellent add :) —Preceding unsigned comment added by 71.238.99.136 (talk) 23:50, 12 September 2008 (UTC)

Dead code is not the same as unreachable - articles redone

Vis-a-vis standard and published definitions of dead code, redundant code, and unreachable code, I have updated and changed the articles for dead code, redundant code, and unreachable code. --Dorchard (talk) 22:51, 20 October 2008 (UTC)

I do not wish to get in a revert war over this. Please check the references- I can find more if necessary. The Appel book is a VERY common course book for Compilers and Optimizing Compiler courses at Undergraduate level for Computer Science and Software Engineering degrees. The definitiions of dead code and unreachable code being equivalent is false. I would not want any students to read this and get confused. —Preceding unsigned comment added by Dorchard (talk • contribs) 08:56, 21 October 2008 (UTC)

---

Causes section

The causes section is uncited and looks a bit like OR to me. Isn't the 4th bullet point ("While fixing one bug ...") a subset of the first. I can think of at least 2 cases where a program deliberately has unreachable code that aren't mentioned here (e.g. a software model of a robot includes code representing hardware safety mechanisms some of which are unreachable in the model). Should this section be deleted ? DexDor (talk) 22:18, 3 March 2012 (UTC)